Re: [conex] draft-ietf-conex-tcp-modifications-00.txt

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

> 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….

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)

> 
> Mirja
> 
> 
> On Friday 03 February 2012 02:14:33 John Leslie wrote:
>> internet-drafts@ietf.org <internet-drafts@ietf.org> wrote:
>>> 	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
>> 
>>   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 <john@jlc.net>
>> _______________________________________________
>> conex mailing list
>> conex@ietf.org
>> 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: mirja.kuehlewind@ikr.uni-stuttgart.de
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex