[e2e] SEuCN

[Katsushi Kobayashi]

Hi,

I submitted the mechanism to retrieve per hop router information
using XCP-like mechanism.

http://www.ietf.org/internet-drafts/draft-kobayashi-sirens-00.txt

Although more than hop count packets
is required to complete end-to-end path, the overhead may not be
serious. That's why more than 800 packets are sent at a bandwidth
of 100 Mbps, an RTT of 100 ms, and an MTU of 1500 bytes.

Regards,

On 2005/11/07, at 14:28, Jon Crowcroft wrote:

> 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,