Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-00.txt

From: [email-masked]
Date: Wed, 01 Feb 2012 14:56:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF.

	Title           : TCP modifications for Congestion Exposure
	Author(s)       : Mirja Kuehlewind
                          Richard Scheffenegger
	Filename        : draft-ietf-conex-tcp-modifications-00.txt
	Pages           : 12
	Date            : 2011-12-21

   Congestion Exposure (ConEx) is a mechanism by which senders inform
   the network about the congestion encountered by previous packets on
   the same flow.  This document describes the necessary modifications
   to use ConEx with the Transmission Control Protocol (TCP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-tcp-modifications-00.txt

---

From: John Leslie <[email-masked]>
Date: Thu, 2 Feb 2012 20:14:33 -0500

> 	Filename        : draft-ietf-conex-tcp-modifications-00.txt

   I'd like to concentrate on Section 3.

] 3. Accounting congestion
] 
] A TCP sender MUST account congestion byte-wise (and not packet-wise)
] based the congestion information received by ECN or loss detection
] provided by TCP.

   I am unmoved in my belief this is a bad idea, though I remain willing
to make byte-counting vs. packet-counting part of the experiment.

] For this purpose a TCP sender will maintain two different counters for
] number outstanding bytes that need to be ConEx marked either with the
] E bit or the L Bit.

   Regardless, let's follow this proposal...

] The outstanding bytes accounted based on ECN feedback information are
] maintained in the congestion exposure gauge (CEG).  The accounting of
] these bytes from the ECN feedback is explained in more detail next.
] 
] The outstanding bytes for congestion indications based on loss are
] maintained in the loss exposure gauge (LEG) and the accounting is
] explained in subsequent to the CEG accounting.
] 
] The subtraction of bytes which have been ConEx marked from both
] counters is explained in the next section.

   (Just so I don't get accused of selective quoting.)

] Usually all byte of an IP packet must be accounted.

   This invites interoperability questions. What _are_ "all the bytes"?
One could guess it includes every last byte of every IPv6 header but
none of the Ethernet (or other encapsultion) bytes. But guessing is a
really-bad thing here.

] If we assume equal sized packets or at least equally distributed
] packet sizes the sender MAY only account the TCP payload bytes,
] as the ConEx marked packets as well as the original packets causing
] the congestion will both contain about the same number of headers.

   I don't believe that necessarily follows. Even if it did, it would
amount to guess-work. :^(

] Otherwise the sender MUST take the headers into account.

   That could be a problem. The needed TCP modifications will get
implemented in different parts of the system; and in some cases the
modified code will have no way to know all the headers that may
appear in the packet.

   But even worse, there are middleboxes that _do_ add headers; and
if routing headers are involved, they are liable to be removed partway
through the packet's progress.

] A sender which sends different sized packets with unequally
] distributed packet sizes

   I'm not sure what "unequally distributed packet sizes" means. :^(

] should know about reason to do so and thus may be able to reconstruct
] the exact number of headers based on this information.

   I don't understand. Assuming the authors meant "exact number of
header bytes", I still don't see how this could be more than a guess.

] Otherwise if no additional information is available the worse case
] number of headers SHOULD be estimated in a conservative way based on
] a minimum packet size (of all packets sent in the last RTT).

   That could get _dreadfully_ conservative.

   I don't know at exactly what point gross overestimates of congestion
volume might become a problem, but it seems at first glance this could
run afoul of ISP limits on ConEx marking for a particular class of
service.

   (The rest of Section 3 goes into detail of inferring packet loss
which I'd prefer not to go into at this time.)

   We cannot reasonably require counting bytes unless we define exactly
how to count them, and have some reason to believe that two observers
along the path will agree on the count. IMHO we're not there yet.

   Counting packets is _so_ much easier; and I'd _really_ like this
WG to discuss the benefits we expect to ensue from counting  bytes
instead of packets. So far, I don't see sufficient benefits.

--
John Leslie <[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 3 Feb 2012 09:58:01 +0100

Hi John,

just a quick comment for now: I will rework this section and probably relax 
some of the MUSTs to SHOULDs as, yes, it is guess-work.

But counting packets is guess-work as well. You only now the number of loss 
payload bytes at the TCP layer. To estimate how much packets that have been 
is as much guessing....

Mirja

On Friday 03 February 2012 02:14:33 John Leslie wrote:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 3 Feb 2012 10:18:43 +0000

On 3 Feb 2012, at 08:58, Mirja Kuehlewind wrote:

> is as much guessing….

And in fact you only know the number of packets the TCP sender /thinks/ are lost. 

In actual fact though, TCP IS a byte stream, not a packet stream so to say accounting should be done byte wise is arguably in the spirit of TCP. I would be interested to hear the views of someone in TCPM (I used to be, but not for 3 years or so).

Toby

PS I personally feel packets is correct from a purely pragmatic engineering perspective (in other words, in the IETF spirit rather than the IRTF spirit)

---

From: John Leslie <[email-masked]>
Date: Fri, 3 Feb 2012 09:18:49 -0500

Toby Moncaster <[email-masked]> wrote:
>> just a quick comment for now: I will rework this section and probably
>> relax some of the MUSTs to SHOULDs as, yes, it is guess-work.
>> 
>> But counting packets is guess-work as well. You only know the number
>> of loss payload bytes at the TCP layer. To estimate how much packets
>> that have been is as much guessing?.

   Thank you!

   This is a good basis for discussion. TCP indeed "thinks" strictly in
bytes in interfacing to upper layers, and acknowledgments from the
receiver are denominated in bytes. Thus viewing congestion in bytes is
reasonable.

> And in fact you only know the number of packets the TCP sender /thinks/

   Emphasis on the "lost"...

   Let us not forget the assumption in TCP congestion-control that the
losses indicate congestion -- while in fact we know there are other
reasons packets get lost.

> In actual fact though, TCP IS a byte stream, not a packet stream so
> to say accounting should be done byte wise is arguably in the spirit
> of TCP.

   Of course, TCP "is" a byte stream to upper layers, and a packet
stream to lower layers...

   But yes, accounting in terms of bytes probably _is_ "in the spirit
of TCP".

   However, IMHO, we shouldn't be aiming for the spirit of TCP --
rather we should aim for the spirit of IP. After all, we want our work
to be useful for transports other than TCP eventually.

   To the ISP (which is where I'm coming from), congestion is a matter
of packets, not bytes: there's no significant difference between big
packets and small packets in the congestion they may encounter. I
would like to see something akin to back-pressure telling me that
traffic to a particular destination is congested (not merely showing
packet loss which may be due to excessive noise instead of congestion).

   Will I ever see that -- perhaps not, but I can still wish for it.
I'm definitely glad we're proposing to notate loss separately from
ECN marking in ConEx marking.

   Probably Mirja and others enjoy figuring out how to infer congestion
in the absence of ECN or other explicit congestion signals -- to me,
this is uninteresting and possibly mis-directed. (But I'm glad someone
is working on that!)

> I would be interested to hear the views of someone in TCPM (I used to
> be, but not for 3 years or so).

   We could work on how to ask them, but someone actually active there
should pose the question. Perhaps something to the effect of
" 
" The folks in ConEx are working on how to account for congestion along
" the path from sender to receiver, in a manner visible to all nodes.
" There is discussion about whether it's better to count bytes or
" packets. Do any of you want to chime in on that?

> PS I personally feel packets is correct from a purely pragmatic
> engineering perspective (in other words, in the IETF spirit rather
> than the IRTF spirit)

   Of course I agree -- and I'd argue that this is an IETF WG, not an
IRTF RG...