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

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:
> 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
-------------------------------------------------------------------