Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion

From: [email-masked]
Date: Tue, 24 Jun 2003 06:08:47 +0300

Hi all,

As I said before, this is protocol stuff, not framework stuff.
There is WG consensus that the framework document should
say that NTLP handles fragmentation when needed.  I don't
think we should pile extra text, conditional clauses or
text around it, we should keep it simple and in the protocol
design phase for NTLP, we cover potential corner cases,
etc.

Unless there is strong opposition to this position, I think
we should move on.

John

> -----Original Message-----
> From: ext Hancock, Robert [mailto:[email-masked]]
> Sent: 24 June, 2003 02:24
> To: Bob Braden; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] yet another attempted summary of fragmentation
> discuss ion
> 
> 
> dear all,
> 
> so, what do others think?
> 
> one point i would emphasise is that this would be a feature 
> we add to the
> NTLP
> for the benefit of signalling applications that might want 
> it; it doesn't
> do anything to protect NTLP implementations from fragmentation load. 
> 
> at the moment I can't see a signalling application that would 
> want this 
> facility (which is primarily a performance optimisation), but 
> on the other
> hand we are supposed to be designing for the future.
> 
> the one circumstance where i could see this facility being 
> useful would be
> where a signalling application needed to transfer gigantic 
> amounts of data
> between peers (an authorisation object containing a video 
> clip?) and wanted
> to discover the best size to which to segment its own data. 
> but then i think
> we'd be better to define a mandatory-to-implement signalling 
> MTU discovery 
> NSLP which would return the answer in one go, rather than 
> some trial and 
> error mechanism.
> 
> r.
> 
> PS. while the IP experience may be relevant, i don't see that the
> conclusions
> have to be the same. after all, one of the main points of DF 
> in IP is to
> allow TCP streams to segment their data optimally, since TCP 
> is far better
> at
> reassembly than IP is. if the NTLP is that bad at 
> reassembling fragments -
> essentially through unreliability - then we should probably change
> something.
> 
> why else is DF used?
> 
> > -----Original Message-----
> > From: Bob Braden [mailto:[email-masked]]
> > Sent: Monday, June 23, 2003 19:02
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [NSIS] yet another attempted summary of fragmentation
> > discuss ion
> > 
> > 
> > 
> > Attila,
> > 
> > Your argument about fragmentation is supported by the analogy of the
> > Don't Fragment (DF) bit in the IP header.  The same argument 
> > I made for
> > NSIS could be applied to the DF bit [I did, and I was 
> wrong... DF did
> > turn out to be useful in triggering an error signal.  I 
> guess we don't
> > always learn from our mistakes.]
> > 
> > So I accept that there is an argument for a DF bit in the 
> > NSLP <-> NTLP
> > interface.
> > 
> > Bob Braden
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> 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: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 24 Jun 2003 10:07:08 +0200

Hi John

Are you also saying that the DF bit solution is not excluded and it will be
covered during the
design phase of NTLP?
 If yes then I agree with your proposal.

Best Regards,
Georgios

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 24, 2003 5:08 AM
Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss
ion