rimac at bell-labs.com
Tue Nov 8 08:24:42 PST 2005
> 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.
> >>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051108/d5f51c31/smime-0001.bin
More information about the end2end-interest