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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Jun 2003 11:06:21 +0100

hi sven,

i think what you say is correct - if a message doesn't need fragmenting,
then the NTLP doesn't need to be told not to do it. this is part of my
overall confusion about option 4. 

the missing part of the picture for option 4 is how the originating NSLP
does the MTU discovery, which is a non-trivial question which there seems
to be some resistance to addressing.

robert h.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 12 June 2003 10:56
> To: Hancock, Robert
> Cc: [email-masked]'
> Subject: Re: [NSIS] attempted summary of fragmentation discussion
> 
> 
> Hi Robert, all,
> 
> I have followed this thread from a slight distance so I might 
> have missed
> something obvious but I am wondering about the following 
> issue: if someone
> wants to do fragmentation in his or her NSLP instead of in 
> the NTLP, why
> does it have to be signalled to the NTLP? In order to do a 
> good job, the
> NSLP would need to know the MTU of the path to the next 
> NSLP-aware entity
> and would then need to make the message parts it sends small enough. I
> would say it is completely transparant to the NTLP which, if 
> the NSLP has
> done its job properly, will not need to fragment anymore. But 
> it doesn't
> need to be told that.
> 
> Sven
> 
> 
> 
> 
> 
> "Hancock, Robert" <[email-masked]>@ietf.org on 12/06/2003
> 11:21:26
> 
> Sent by:    [email-masked]
> 
> 
> To:    "[email-masked]'" <[email-masked]>
> cc:
> Subject:    [NSIS] attempted summary of fragmentation discussion
> 
> 
> dear all,
> 
> in attempting to summarise where we are so far, this is what 
> i think the
> situation is:
> 
> 1) no-one really likes relying on IP fragmentation
> 2) no-one wants to force all responsibility into the NSLPs
> 3) everyone [almost?] is happy with the NTLP doing fragmentation as a
> default
> 4) there is a proposal to make it possible to signal the NTLP 
> not to do
> fragmentation and have the NSLP do it (in some 
> still-to-be-defined way)
> 
> personally, i fail to see the benefit of (4) over (3), which may be a
> symptom of a deeper problem (with me or the proposal).
> 
> however, i believe it is not ruled out even if we used as an initial
> position:
> *) make the NTLP do fragmentation when it is needed; ideally, 
> do it in such
> a way that reassembly is only needed at the receiving NSLP.
> 
> in later stages of the protocol work, and after some experience with
> applications, we could presumably "enhance" the NTLP in the 
> direction of
> option 4, i.e. give it the ability not to do fragmentation as 
> well. after
> all, this would appear to be an intrinsically backwards compatible
> extension.
> 
> have i missed anything?
> 
> robert h.
> _______________________________________________
> 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: Melinda Shore <[email-masked]>
Date: Thu, 12 Jun 2003 09:31:06 -0400

The NSLP doesn't know whether or not it's being bundled,
which is a not-so-trivial impediment to having the NSLP
making fragmentation decisions.  

It's conceivable that we could add a bit to an API to tell
the NTLP not to bundle a given NSLP, but I think that we're
tending towards getting complexer faster than we're getting
usefuler.

Melinda

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 12 Jun 2003 15:52:49 +0200

> making fragmentation decisions.

I think this are two different orthogonal issues. The decision on bundling 
is in the NTLP, I hope that it does not bundle if afterwards fragmentation 
is needed.

> tending towards getting complexer faster than we're getting

Whether bundling makes anything easier needs to be proved.

Marcus

> Melinda

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jun 2003 10:05:28 -0400

> Whether bundling makes anything easier needs to be proved.

Absolutely, and I think it's arguable that it does provide a
good cost/benefit tradeoff.  However, we agreed that we
would start with 2205 + 2961, and bundling is included in
2961.  We can excise it later if there's agreement that it
adds undue complexity (Saint-Exupery on protocol design:
"Perfection is achieved, not when there is nothing more to
add, but when there is nothing left to take away").  I hope
we can be consistently rigorous about avoiding unnecessary
complexity.

Melinda