[e2e] SEuCN

[Ivica Rimac]

Hello Jon,

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

but maybe we can even avoid any state just by using "encoding": 
initially, the sorce sets the lowest bit of each apcket to "1" and all 
others are set to "0". at each hop a bit-shift operation is performed 
and the lowest bit is set according to the congestion state.
As a result, the routers do not have to worry about the index and the 
end host can extract the number of hops from the index of the "highest" 
1. no ttl necessary.

8 bit example
--------------
Sender:               0000 0001
1. Router (okay):     0000 0011
2. Router (cong):     0000 0110
....
6. Roter  (cong):     0110 1110
Receiver:             0110 1110

(To handle even overflow situations, we could use the highest bit for 
indication of overflow.)

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

obviuos, ECN uses just a single bit ;-)


> 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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051108/d5f51c31/smime-0001.bin