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

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> 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 <[e-mail]>