[e2e] Routers accessing TCP header

[Jon Crowcroft]

so if a router is dropping packets beause of queues being full then 
for EPDN to work reasoanbly well, you are going to end up
keeping on the order of the number of flows worth of state (although the amount of state aint that much
it will at least be the 5 tuple to identify flow, plus sequence number so 16 bytes or more...)

the rate of access to this wil ldepend on the nature of the EPDN mech - e.g. if its like ECN, 
you only need to mark a flow with binary feedback, but if its part of the +reliability+ scheme,
you need to correctly "nack" each missed packet...so that ends up being quite a lot of processing...

I guess the assumption is that packets either get delivered end to end, with or without ECN 
(early warning) or they are knowingly dropped (EPDN) or lost without knowledge 
(need to rely on fast recovery etc)...

so i suppose if ECN is operating right, EPDN would be rare...but without ECN, or with end systems that dont respond
to ECN right, EPDN is going to dominate - and thats not going to be sustainable unless its in the edge router (and
it might be as most ISPs claim there's little congestion if any in the core  and most IXPs now claim there's little
congestion in the Internet Exchanges either (certainly true at the LINX where i've seen the figures:)

In missive <41004.137.73.8.3.1108988356.squirrel at 137.73.8.3>, "Arjuna Sathiaseelan" typed:

 >>  Thanks for your appropriate reply. I am basically working on a mechanism
 >>called the Explicit Packet Drop Notification (EPDN). EPDN works like
 >>this : Every router has a hashtable which stores the flow id and the
 >>maximum and minimum sequence numbers of the dropped packets. This
 >>information will then be inserted into a packet of that particular flow
 >>that passes through the gateway successfully. The receiver in turn runs
 >>a series of algorithms to detect whether a missing packet is dropped or
 >>not. Based on this the receiver informs the sender about the cause of
 >>the inorder packet.  We do not maintain per flow state - just the state
 >>of flows of dropped packets.
 >>
 >>
 >>Now this mechanism infact has lots of limitations such as not incremental
 >>and requires all the gateways to be implemented with the EPDN mechanism
 >>and as you said requires lots of CPU cycles for deep packet inspection.
 >>
 >>Do you think this type of mechanism has any future in real world
 >>implementation and do you feel that maintaining the max and min sequence
 >>numbers of dropped packets is a possibility given that there is IP
 >>fragmentation going on?
 >>
 >>Your suggestions will be really helpful..
 >>
 >>Regards,
 >>Arjuna
 >>
 >>

 cheers

   jon