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 1990 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
- Minutes of MTU Discovery Working Group Meeting (7… Jeffrey Mogul
- Re: Minutes of MTU Discovery Working Group Meetin… Steve Deering
- Re: Minutes of MTU Discovery Working Group Meetin… Philippe Prindeville
- Re: Minutes of MTU Discovery Working Group Meetin… Steve Deering