[Iccrg] Small packets open issue: draft-briscoe-tsvwg-byte-pkt-mark-02

[Bob Briscoe]

Folks,

This draft relates closely to the open research issue on small 
packets, which I assume will be part of our discussions in Manchester 
(I'll be there BTW).
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>

I believe we really should get our views on basic questions like the 
relation between packet size and congestion sorted out better.

The draft has a split personality:
1/ a recommendation for now (afterall, it's an IETF TSVWG draft)
2/ stuff to set aside for future research (Section 7)

Section 7 "Open Issues & Next Steps" is devoted to discussing open 
issues concerning packet size & congestion. Complementing 
draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt, it 
goes into depth on a couple of aspects of the issue, rather than 
trying to identify the breadth of issues.

Having written this, I now have a list of sub-questions to the question
"What type of drop was it?"
- transmission loss *OR* congestion *OR* policing?
- packet-rate congestion *OR* bit-rate congestion?  <<<--- this draft

I argue we should solve all these problems at once, not just 
"transmission vs congestion" on it's own.

I originally wrote the draft after I went through the welzl-eddy 
survey of cc RFCs to identify those RFCs with gaps/problems. I only 
found a couple. This draft is designed to fill a gap in the RED 
manifesto (RFC2309), which is also needed now for guiding the 
pre-congestion notificaton algo work in the PCN w-g.

Links and outline of changes are in the mail to tsvwg below.

Cheers


Bob

>Date: Tue, 26 Feb 2008 16:26:17 +0000
>To: "tsvwg IETF list" <tsvwg at ietf.org>
>From: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
>Subject: Updated: drop by packet size? draft-briscoe-tsvwg-byte-pkt-mark-02
>
>Folks,
>
>I've updated this one largely based on conversations at the last 
>IETF with Sally Floyd & (and a bit with Fred Baker). Changes from 
>-01 to -02 pasted at the end of this mail.
><http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>
>
>Sally raised the question of whether I thought 'buffer carving' (as 
>used by certain Cisco routers for instance) was wrong, given it 
>advantaged small packets. With buffer carving, fixed sized buffers 
>are allocated in pools for different size packets.
>
>I've clarified that the reduced drop probability that small packets 
>get from such memory architectures is legitimate, given small 
>packets can fit into more buffers than large packets, so they 
>congest fixed sized buffers less.
>
>But I've also tried to explain better why designing an AQM to 
>deliberately further advantage small packets is incorrect and 
>potentially dangerous. To help, I've described a test for whether a 
>congestion control scales with packet size.
>
>My intent is for informational. I've had some off-list feedback 
>saying it really helped explain the issues, so pls go ahead and 
>bash. Packet size dependency is a tricky subject to get your head 
>round, so informed discussion would be useful.
>
>Cheers
>
>
>Bob
>
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
>Changes from Previous Versions [pasted from the draft]
>
>    To be removed by the RFC Editor on publication.
>
>    Full incremental diffs between each version are available at
>    <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#byte-pkt-mark>
>    (courtesy of the rfcdiff tool):
>
>    From -01 to -02 (this version):
>
>          Abstract reorganised to align with clearer separation of issue
>          in the memo.
>
>          Introduction reorganised with motivating arguments removed to
>          new Section 2.
>
>          Clarified avoiding lock-out of large packets is not the main or
>          only motivation for RED.
>
>          Mentioned choice of drop or marking explicitly throughout,
>          rather than trying to coin a word to mean either.
>
>          Generalised the discussion throughout to any packet forwarding
>          function on any network equipment, not just routers.
>
>          Clarified the last point about why this is a good time to sort
>          out this issue: because it will be hard / impossible to design
>          new transports unless we decide whether the network or the
>          transport is allowing for packet size.
>
>          Added statement explaining the horizon of the memo is long
>          term, but with short term expediency in mind.
>
>          Added material on scaling congestion control with packet size
>          (Section 2.1).
>
>          Separated out issue of normalising TCP's bit rate from issue of
>          preference to control packets (Section 2.3).
>
>          Divided up Congestion Measurement section for clarity,
>          including new material on fixed size packet buffers and buffer
>          carving (Section 4.1.1 & Section 6.2.1) and on congestion
>          measurement in wireless link technologies without queues
>          (Section 4.2).
>
>
>
>
>____________________________________________________________________________
>Notice: This contribution is the personal view of the author and 
>does not necessarily reflect the technical nor commercial direction of BT plc.
>____________________________________________________________________________
>Bob Briscoe,                           Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196