Subject: RE: [NSIS] attempted summary of fragmentation discussion

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 17 Jun 2003 23:32:24 +0100

mike,

i think at least one stage of PMTU discovery has to take place between
(adjacent) NTLP peers. ICMP 'too big' messages from between the two will
be hard for any other type of end system (whatever 'end' means) to
interpret,
given the manipulations that might be done by the NTLP; if the NTLP is
providing channel level security, no-one else will even be able to tell
what message it is that is too big. NTLP-level PMTU discovery is a load
for the NTLP, but it seems unavoidable to me - especially if NTLP messages
themselves need fragmentation.

if the NTLP itself does all the fragmentation, that's clearly all that is
needed.

if fragmentation is to be done at the NSLP, there needs to be a second
'outer'
level of PMTU discovery. i would see this only being done between adjacent
NSLP peers (of course, they could still be on opposite sides of the
network),
there doesn't seem to be any point in going further than that, only 
disadvantages.

cheers,

robert h.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, June 13, 2003 22:14
> To: Melinda Shore
> Cc: Michael Thomas; [email-masked]
> Subject: Re: [NSIS] attempted summary of fragmentation discussion 
> 
> 
> Melinda Shore writes:
>  > > Does PMTU (re)discovery always have to be from 
>  > > end host to end host?
>  > 
>  > What's an "end host" in this context?
> 
> The host at which the reservation is turned
> around?  Ie, the thing that takes a PATH and
> generates a RESV.
> 
> 	    Mike
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Jun 2003 15:45:10 -0700 (PDT)

I apologize for being so obscure about where I was
headed with this. One of the things that would be
extremely advantageous with an NSIS is to pay
close attention to local convergence issues on
moves. That is, we would like to have a protocol
which does not require round trips all the way to
an end node -- which might be half a world away --
to heal a reservation from a move. It would be
much better to only require signaling to the join
point between the old and new location and no
farther into the network. 

Thus, if PMTU discovery is required again upon
arriving at a new attachment point, it's probably
double plus ungood since I think that PMTU
discovery is an end to end process. Naively, it
would seem to be the case that you'd need to
re-run PMTU discovery upon movement if you have
MTU-size considerations.

		Mike

Hancock, Robert writes:
 > --
 > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
 > Berkshire. RG12 8FZ
 > 
 > The information contained in this e-mail and any attachments is confidential to
 > Roke Manor Research Ltd and must not be passed to any third party without
 > permission. This communication is for information only and shall not create or
 > change any contractual relationship.