ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

2017-02-02 05:08:40
On 02/02/2017 07:21 AM, Eggert, Lars wrote:
On 2017-2-2, at 10:54, Fernando Gont <fgont(_at_)si6networks(_dot_)com> wrote:
On 02/02/2017 06:37 AM, Eggert, Lars wrote:
Also, even if ICMP delivery is assured, there are additional 
complications for UDP, which has been seeing a lot of interest
both as a tunneling encapsulation and for applications (e.g.,
QUIC). Many platforms do not provide UDP-sending applications any
information about arriving ICMP messages that were triggered by
their transmissions. So even if the path delivers ICMP, the OS
makes ICMP-based PMTUD for UDP often impossible. Another reason
to recommend 4821?

Agreed... although in this case this would be more of an app-layer 
implementation than one at the transport layer?

There are two dimensions here, one is in kernel vs. in userspace, the
other which "layer" something is at. It used to be that "transport
layer" (or "network layer" always implied "in kernel", but those days
are past.

I was refering to "layer" as in a reference model. i.e., PMTU assumes
that you can repacketize your data. For TCP, that can be done at the
transport layer, since it's byte-stream oriented. OTOH, UDP is
essentially record-based... so any "re-packetization" must be done at
the upper (app) layer.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




<Prev in Thread] Current Thread [Next in Thread>