Subject: [pmtud] Re: [dccp] PMTU issues

From: Michael Welzl <[email-masked]>
Date: 14 Nov 2003 08:50:58 +0100

Hi,

I'm CC'ing the PMTUD list because I think that this has
some relevance to them.

> So, if an app uses that initial PMTU value, and it's too big (which seems
> fairly likely in this world of tunnels of various kinds),  it's going to
> routinely lose its first few packets (maybe only one).  I can't imagine that
> this is a situation apps would like.

If I understand things correctly, the real difference between
PMTUD/TCP and PMTUD/DCCP then is that with TCP, PTMUD is transparent
to the application ... i.e. TCP loses a few initial packets but
it doesn't really matter because this is unnoticed by the
application - right?

> So, assuming that this is a real problem, there are two solutions I see,
> neither of them very elegant:
> 
> 1)  Start the connection by sending some probe packets.  Note that this
> means getting feedback that they were delivered before going on with the
> real work.
> 
> 2)  Never send packets bigger than some size that's likely to be OK, but is
> probably less than the PMTU that DCCP says.  And be prepared to adjust down
> from that in the few situations where it's necessary.  It's probably pretty
> difficult to come up with this recommended "safe" PMTU.
> 
> Comments?

I agree that we seem to have a problem here, and I agree that
these solutions are both inelegant. A solution would be start
with a small MTU and gradually increase it, as it is currently
being proposed in the PMTUD working group. This way, the lost
packets are not at the very beginning of the connection, and
there may be less loss. In any case, as this is still in the
making, PMTUD/DCCP sounds like something the PMTUD group should
consider.

I have another proposal, which is quite different and certainly
not a replacement for others (i.e. not immediately available),
but it might be a really good fit here and so I'm mentioning it:

Include IP options that query for the MTU (routers with smaller
MTU's need to update the packet) at connection start-up.

Basically, this is a revival of RFC1063, but now combined with
PMTUD - the idea is to do this initially and interpret the
result as an upper limit for the PMTUD process (never exceed
this value, use it as a start or end point, depending
on whether you do RFC1191 or the new variant). Depending on
which routers supported it, this may lead to lossless PMTUD.

I know that there are several issues with this - I'm
working on a draft and putting some serious effort into
it, it's just a question of time. The idea is not necessarily
to include this in each and every TCP SYN as it is extra
effort for routers etc., but it can be valuable in special
situations, e.g. with tunnels or maybe with DCCP (because an
application may decide to have a packet delayed to reduce
the chance of PMTUD packet loss).

Slow path processing is of course one particular problem,
but it may be less severe than you think it is: we did
measurements in 2001 and 2003 which involved 75000+ different
router addresses (not necessarily as many different
machines - hard to tell). After some statistics, it looks
like the delay at each router is approximately 1%. This,
at least, indicates the order of magnitude.

This study will soon be available as a technical report;
for now, all I have is a very preliminary version of the draft:
http://www.welzl.at/tmp/draft-welzl-mtuoption-preliminary.txt
... I'm working on it.

Best regards,
Michael

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 14 Nov 2003 19:55:19 +0900 (JST)

> it doesn't really matter because this is unnoticed by the

	essentially the problem DCCP has seem to be the same as UDP, am i right?

itojun

---

From: Michael Welzl <[email-masked]>
Date: 14 Nov 2003 12:33:25 +0100

> 	essentially the problem DCCP has seem to be the same as UDP, am i right?

Ah yes, absolutely! Right?!

So this seems to be a very sensible position for my options
idea - it's an experimental feature that UDP / DCCP / .. users
might enjoy trying out.

Cheers,
Michael

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Nov 2003 13:00:29 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Matt and I came up with a heuristic for what IPsec gateways should do
when encapsulating. The goal is to permit a solution that IPsec gateway
vendors can use *TODAY* to deal with ICMPs going missing, that still works
if the ICMPs are effective, and will not break the new proposal for
PMTU, which does not rely on getting ICMPs back. 

My strawman text needs a revision as it was overly complicated in its
wording, which I hope to do before Monday.  

RFC2401bis specifies more behaviour for PMTU, which I think that
this (PMTUD) WG should take on as a review item.

What I don't know is what we can do for IPsec gateways to determine
actual (outer) size of the tunnel in question. (in the case where
the tunnel experiences an MTU constraint between security gateways).
 
This affects whether or not the DF bit should be copied - if the ICMPs
are missing, (or ineffective, as they don't return enough info, of
it the tunnel carries multiple sources of traffic) then it isn't clear 
how to make things work.

Note that fragmentation before encapsulation can present risks if in high
speed networks, particularly when they use large TCP windows. Matt explained
the situation to me, which made my mouth hang open when I realized what was
up. 

Fragmentation of the ESP packet is somewhat better, if the ESP is doing
integrity, as it has much stronger integrity check than the tunneled
TCP. I.e. if the fragments get reassembled wrong, the integrity check is
almost guaranteed to fail. 

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [