Subject: [Tsvwg] Updated: drop by packet size? draft-briscoe-tsvwg-byte-pkt-mark-02

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Feb 2008 16:26:17 +0000

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