Re: yet another MTU discovery scheme
Steve Deering <deering@pescadero.stanford.edu> Sun, 25 February 1990 20:54 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34)
id AA25512; Sun, 25 Feb 90 12:54:10 PST
Received: by decwrl.dec.com; id AA05027; Sun, 25 Feb 90 12:54:07 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA16106;
Sun, 25 Feb 90 12:53:38 PDT
Date: 25 Feb 1990 12:38-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: yet another MTU discovery scheme
Cc: mtudwg
To: Philippe Prindeville <philipp@gipsi.gipsi.fr>
Message-Id: <90/02/25 1238.824@pescadero.stanford.edu>
In-Reply-To: Philippe Prindeville's message of Sun, 25 Feb 90 140055 -0100
> Your scheme (actually, as you point out it has come up before) would > seem to suffer when trying to find the MTU if a Can't Fragment message > is lost en route... Depending on the search technique, it could cause > quite poor behaviour. A lost Can't Fragment message simply results in transport-layer timeout and retransmission, just like any packet loss. No big deal. I don't understand your comment about "search technique". The whole point of my variation on the old scheme is that it doesn't require a search. Steve
- yet another MTU discovery scheme Steve Deering
- Re: yet another MTU discovery scheme Philippe Prindeville
- Re: yet another MTU discovery scheme Steve Deering
- Re: yet another MTU discovery scheme Philippe Prindeville
- Re: yet another MTU discovery scheme Philippe Prindeville
- Re: yet another MTU discovery scheme Steve Deering
- Re: yet another MTU discovery scheme Steve Deering