Subject: Re: Fwd: New Version Notification for draft-ietf-tsvwg-byte-pkt-congest-05.txt

From: Bob Briscoe <[email-masked]>
Date: Tue, 27 Mar 2012 09:09:25 +0100

Mirja,

I've taken the liberty of cc'ing my reply to the list.

At 00:57 27/03/2012, Mirja Kuehlewind wrote:
>Hi Bob,
>
>had  a quick read on the draft. I have two more questions/comments:
>
>- Shouldn't RFC 3465 (TCP Congestion Control with Appropriate Byte Counting
>(ABC)) be mentioned somewhere?

ABC is about size of ACKs. byte-pkt-congest is about size of NACKs.

I thought I'd written somewhere that "ABC seems 
relevant but it isn't really". I've checked 
previous revisions and it doesn't seem to be 
there (altho RFC3465 is a commented out reference 
in the XML source of byte-pkt).

>- Do you have a reference that says taht most network resources are
>bit-congestible? I though that many home routers are packet-congestible
>because the memory is most cheapest part...?

Yes, this is a critical point. The only ref we 
could give was [RFC6077; S.3.3], which records 
the 'expert opinions' of equipment vendors at an ICCRG workshop in 2008.

"  Today, many network resources are designed so that packet processing
    cannot be overloaded even for incoming loads at the maximum bit rate
    of the line.  If packet processing can handle sustained load r
    [packet per second] and the minimum packet size is h [bit] (i.e.,
    frame, packet, and transport headers with no payload), then a line
    rate of x [bit per second] will never be able to overload packet
    processing as long as x =< r*h.

    However, realistic equipment is often designed to only cope with a
    near-worst-case workload with a few larger packets in the mix, rather
    than the worst-case scenario of all minimum-size packets.  In this
    case, x = r*(h + e) for some small value of e.  Therefore, packet
    congestion is not impossible for runs of small packets (e.g., TCP
    ACKs or denial-of-service (DoS) attacks with TCP SYNs or small UDP
    datagrams).  But absent such anomalous workloads, equipment vendors
    at the 2008 ICCRG meeting believed that equipment could still be
    designed so that any congestion should be due to bit overload and not
    packet overload.
"

The acknowledgements in RFC6077 say:
"   The authors would like to thank the following people whose feedback
    and comments contributed to this document: ...
    ... Larry Dunn (his comments at the Manchester ICCRG
    and discussions with him helped with the section on packet-
    congestibility).
"
After Larry made this point, there was a poll 
among the other equipment vendors in the room, and they all agreed with him.

I know that's not sceintific, but it's the best ref we could give.

Bob

>Mirja
>
>
>On Sunday 25 March 2012 23:56:42 Bob Briscoe wrote:
> > Mirja,
> >
> > Thanks for your review comments on this one before.
> >
> > Gorry will be asking on Tue morning whether this is now ready to
> > progress, and who has read the latest version.
> >
> > As you've already read it, I thought it might help to give you the
> > diffs since the -04 version, which is the one I think you read (-06 &
> > -07 only changed trivia)
> > 
> <http://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-byte-pkt-congest-04&di>fftype=--html&submit=Go!&url2=draft-ietf-tsvwg-byte-pkt-congest-07>
> >
> > The summary of changes is in the mail below (or in the final appendix
> > of the doc).
> >
> >
> >
> >     From -04 to -05:
> >
> >        *  Changed from Informational to BCP and highlighted non-normative
> >           sections and appendices
> >        *  Removed language about consensus
> >        *  Added "Example Comparing Packet-Mode Drop and Byte-Mode Drop"
> >        *  Arranged "Motivating Arguments" into a more logical order and
> >           completely rewrote "Transport-Independent Network" & "Scaling
> >           Congestion Control with Packet Size" arguments.  Removed "Why
> >           Now?"
> >        *  Clarified applicability of certain recommendations
> >        *  Shifted vendor survey to an Appendix
> >        *  Cut down "Outstanding Issues and Next Steps"
> >        *  Re-drafted the start of the conclusions to highlight the three
> >           distinct areas of concern
> >        *  Completely re-wrote appendices
> >        *  Editorial corrections throughout.
> >
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design
>
>
>
>--
>-------------------------------------------------------------------
>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
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design