[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pmtud] RE: [dccp] PMTU issues
Matt,
I'm thinking about the same thing ... why don't we
build that into the OS as a service? To start with,
it could be a service that gives me a packet size and
a flag "still searching / mtu found", and when I send
something using the suggested packet size (and the
flag said "still searching") and request the DF bit
to bet set, the OS notices that I'm obviously still
participating in the Path MTU process, so it reacts
upon receiving / not receiving an ICMP error message
and updates its internal state ... thus, the next time
I call the "give me a packet size" function, it has
a new value. And so on.
Something like that could work, couldn't it?
Cheers,
Michael
On Fri, 2003-11-14 at 16:06, Matt Mathis wrote:
> This conversation about UDP apps has inspireed me to specificlly cover that
> case in the next iteration. Has anybody tried to implement pmtud using UDP?
>
> I have a hunch that there are some API gotchas for current OS's.
>
> Thanks,
> --MM--
>
>
> On Fri, 14 Nov 2003, Phelan, Tom wrote:
>
> > Hi Michael,
> >
> > See inline ...
> >
> > Tom P.
> >
> > > -----Original Message-----
> > > From: Michael Welzl [mailto:michael.welzl@uibk.ac.at]
> > > Sent: Friday, November 14, 2003 2:51 AM
> > > To: Phelan, Tom
> > > Cc: 'dccp@ietf.org'; pmtud@ietf.org
> > > Subject: Re: [dccp] PMTU issues
> > >
> > >
> > > 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?
> >
> > Yes, that's the problem that I see.
> >
> > > > 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.
> >
> > Thanks, that's very helpful. I'll take a closer look at PMTUD, and the
> > suggestions you made. Itojun is right (in a subsequent e-mail), this is
> > essentially the same problem that UDP apps face. It's my understanding that
> > most UDP apps limit their packets sizes to something that's likely to be
> > small enough (option 2 in my original e-mail), and often don't set the don't
> > fragment bit.
> >
> > _______________________________________________
> > pmtud mailing list
> > pmtud@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pmtud
> >
--
Michael Welzl <michael.welzl@uibk.ac.at>
University of Innsbruck
_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info: https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html