James & everyone,
I've just posted this. It will appear in internet-drafts shortly, but for
now, you can get it from the link to my page below:
Byte and Packet Congestion Notification
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvwg-byte-pkt-mark-00.txt>
Header block & abstract below.
It is motivated at this time by the need to define whether to take packet
size into account for the marking algo in the PCN w-g. But it's generalised
to give strong advice (unlike my usual style ;) on RED for diff size pkts,
and also relevant to TFRC-SP in DCCP, but it's aimed primarily at tsvwg as
a general transport-area-wide subject.
It includes a survey of >100 vendors asking if they implemented the
byte-mode packet drop variant of RED. With ~10% responses in, they've all
said no.
Cheers
Bob
=============================================================================
Transport Area Working Group B. Briscoe
Internet-Draft BT & UCL
Intended status: Informational June 17, 2007
Expires: December 19, 2007
Byte and Packet Congestion Notification
draft-briscoe-tsvwg-byte-pkt-mark-00
Abstract
This memo was written to clarify how (and whether) to take packet
size into account when notifying congestion using active queue
management (AQM) such as random early detection (RED). The scope
includes resource congestion by bytes and by packet processing, even
though the latter is less common. It answers the question of whether
packet size should be taken into account when network equipment
writes congestion notification, or when transports read it. The
primary conclusion is that RED's byte-mode packet drop should not be
used because it creates a perverse incentive for transports to use
tiny segments. TCP's lack of attention to packet size should be
fixed in TCP, not by reverse engineering network forwarding to fix
transport protocols.
=============================================================================
____________________________________________________________________________
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
