[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ICMP must fragment and IPsec



> From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>

> ...
>     >> ...  I can't think of many cases in the current deployed
>     >> internet where the MTU might change during a
>     >> connection. ...

>     Vernon> There is a vast amount of topology on the edges, what with
>     Vernon> ATM (9180), FDDI (4352), Ethernet (1500 or 1492), PPP (256
>     Vernon> to more than 1500), and Frame Relay.
> 
>   But, do any of these things *change* during the course of a TCP
> connection?

They do, at least for plain-vanilla IP in Silicon Graphic's internal
network.  (Lots of FDDI and some ATM and HIPPI backbones.)  Of course,
anything through the Internet will be probably filtered to 1500, but
anyone with HIPPI, 802.5, FDDI, or some flavors of ATM will have other
PMTU's, at least for "servers on the backbone".  Add a little
redundancy--say a few high-metric backup 1500 links in your campus, and
it's easy to get flappying in your PMTU for some real applications.

For the duration of an HTTP 1.0 transfer, you'd expect the PMTU to be
constant.  I often have TCP connections that stay up for days.  Often
when demand-dialed PPP/ISDN dies, I switch to PPP/modems, and then back
to PPP/ISDN, keeping the same TCP connections alive.  If I followed
conventional wisdom for modems, I'd be switching between 1500 and
something smaller.


>   While the routing on the backbone might change, my guess is that the
> MTU between backbone nodes is almost always going to be more than the
> 1500 typical of a T1. I guess, two networks, that do ATM with their
> supplier could get a much lower MTU if the supplier's ATM backbone
> goes down, and the move their backup T1s. 

Yes, of course, on the "backbone" (whatever that means today).  But
anyone with FDDI, HIPPI, ATM, 802.5, and PPP out in the marches
(marshes?) has other PMTU's some of the time, at least between "big
servers on the backbone."  Consider big NFS servers doing network
backups.


>   I don't agree that getting authenticated PMTU information is
> impossible. 

Again, how?  Say you do authenticate router99.bad.guy.net as the
furshure source of the PMTU info, in whatever form, that you just got.
How do you know that router99.bad.guy.net is in your path?  It seems to
me that if you could know your path reliably, a lot of problems would
be vastly easier, from IP security to IP routing.  For that matter, if
you know which routers that might touch your packets, then also knowing
the MTU's of their links is a trivial addition, and so you don't need
any ad hoc or post hoc Path MTU discoverying, timers, probing, DF-bit
kludges, lost user-data etc.

Well, I guess you could require everyone use a link-state routing
protocol that covers the entire Internet, and have every host maintain
a global link-state table, and pay attention to PMTU, source quench,
etc only from routers that are on a path that is close to the current
minimum for your packets.  Or continually use something like
`traceroute` to map the path, and pay attention only to PTMU info from
close to most recent path.  Or we could get rid of TCP and switch to
XTP--I think the initial route setup of XTP could be changed to track
the path.  Or best, get rid of IP and run TCP over ATM end-to-end.

My point is that (reasonable) packet switching means not knowing who's
moving your packets, at least in large networks, and there's no
escaping the implications of that fact.


Vernon Schryver,  vjs@sgi.com
$dOI+2ztӂjA9&\
.pdefaults
.loc-cshrc
.nevotinit
.gamtables
.signature
.sgihelprc
.insightrc
.Xdefaults