[e2e] SEuCN

[Jon Crowcroft]

well good question -  gosh - perhaps routers can keep a per source prefix state saying what the ttl was, then use
that as a "pretty good guess" as to the index to the bit position to set...for example....

lots of other soft state techniques suggest themselves...

so why is this less good than ECN? seems like its moreinfo - 

what to do with it? well
	multiple bottlenecks
	remocing ambiguity of loss versus ecn
lots of things really - 

miht be _really_ useful, for example, in a on demand MANET multihop route over wireless

for example

what do we gain in transport if we know how many and which hops are probably not congested AND didnt exaperience
loss, on a per packet bassis?

dunno - seems like information is better than no information tho:)

like XCP--

In missive <436FBEEA.8080608 at bell-labs.com>, Ivica Rimac typed:

 >>This is a cryptographically signed message in MIME format.
 >>
 >>--------------ms060206000402050809000606
 >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>Content-Transfer-Encoding: 7bit
 >>
 >>Hi Jon,
 >>
 >>> so reading re-feedback etc, and loss notification, wouldn't it be easier
 >>> given most flows have feedback packets, to have an efficient common case
 >>> encoding 
 >>> 1// the hop count in the net is rarely more than 32
 >>> so lets have a 32bit field which is called SEuCN
 >>> and is 
 >>> Selective Explicit unCongested Notification.
 >>> 
 >>> in outbound backets, each hop sets this bit
 >>> (and its returned in acks) to say "all is well and good here".
 >>
 >>I am curious how each hop would determine the bit it should set? 
 >>Furthermore, since the bit is set in case there is no problem, how 
 >>should an end node know that the x Zeros of the 32/64 bits are not an 
 >>indication of problems but rather that the number of hops the packet 
 >>passed is qual to 32/64-x? Hmm, might use the TTL field to determine the 
 >>hop count and determining the corresponding bit at each hop ...
 >>But naivly asking, what do we gain for the transport layer mechanisms if 
 >>we know how many hops are congested?
 >>It seems to me like the congestion level is much more interesting in 
 >>order to apply different algorithms at different congestion levels on 
 >>the transport layer (e.g., more aggresive increase algorithms, etc.), 
 >>which however would require some mechanisms in the routers.
 >>
 >>Cheers,