Re: Minutes of MTU Discovery Working Group Meeting (7 Feb 1990)

Philippe Prindeville <philipp@Gipsi.Gipsi.Fr> Tue, 20 February 1990 01:56 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA17516; Mon, 19 Feb 90 17:56:40 PST
Received: by decwrl.dec.com; id AA24832; Mon, 19 Feb 90 17:56:33 -0800
Received: from [192.33.166.11] by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA27068; Tue, 20 Feb 90 02:55:48 +0100 (MET)
Received: by gipsi.Gipsi.Fr (4.12/4.8) id AA23471; Tue, 20 Feb 90 02:56:39 -0100 (MET)
Date: Tue, 20 Feb 90 02:56:39 -0100
From: Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
Message-Id: <9002200156.AA23471@gipsi.Gipsi.Fr>
X-Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: mogul
Subject: Re: Minutes of MTU Discovery Working Group Meeting (7 Feb 1990)
Cc: MTU Discovery <mtudwg>

On the Deering proposal, it will not work if deterministic fragmentation
loss causes the first fragment to be dropped.

On Van's traffic observations, I assume these were at LBL.  I have to
ask myself just how (a)typical is LBL...

On the Fox et al proposal, how "clean" (though if it works well this
is obviously acceptable) is having an IP option that triggers an
ICMP message?

I know that ICMP is conceptually "part of" and not "layered upon"
IP, but I still think the protocol should use its own message
type or solely IP options...  for architectural purity, and for
simplicity of implementing, testing, monitoring, etc.

I still like the IPMP message type, though perhaps with some
changed/added fields.

-Philip