[e2e] MTU - IP layer

[Joe Touch]

Loki Jorgenson wrote:
> Joe wrote:
> 
> 
>>MTU is a link payload issue. Path MTU is the min of the MTUs on the
>>path; it is path MTU that is defined E2E.
> 
>   And that doesn't seem like a problem?  I guess if RFC 1191 was
> reliably implemented and Layer 2 fed back to the end-to-end....

See the new PMTUD WG below ;-)

>>Short of that, the only other way is POSITIVE feedback - try larger
>>packets and see what gets through. If it does, report back and use
> 
> that
> 
>>size. That's already under consideration in the IETF "pmtud" working
> 
> group.
> 
>>From the early drafts I looked at they were proposing, as you suggest, a
> "probing for packet loss by size defines pMTU" mechanism  - is that
> still the case then?  That doesn't sound like positive feedback per se.
> The idea of ICMP DF Set probing (a la RFC1191) at least seemed like
> positive feedback, if only best-effort....
> 
> Loki

My use of 'negative' and 'positive' may have been confusing.

I meant more like "the absence of feedback" and "the presence of
feedback". Positive/negative can be confused with the kind of
information you get, _when_ you get feedback (yes it got through, or no
it failed).

So, current pmtud is based on the absence of "no, it failed" feedback.
I.e., if the source gets the ICMP errors back, it knows that particular
attempt failed. The algorithm says "try large until you get told NOT
to", which is _why_ it is susceptible to black holes - because black
holes behave like a working large-mtu path - you do NOT get the feedback
that anything failed.

The new ptmud is based on the presence of "yes, it got through"
feedback. The loss isn't what matters; it's what gets through that does
(successful probes). The algorithm says "stay small, and try large
(disposable) probes; if the probes work, THEN get larger". This is not
susceptible to black holes - it works only when both the probes get
through _and_ the feedback makes it back successfully.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050421/2755b74a/signature.bin