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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 18 Jun 2003 09:38:33 +0100

georgios,

(4) is more complex than (2) because
*) both need fragmentation capability in the NTLP
*) only (4) needs MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the NSLP
*) only (4) needs setting/processing of a 'DF' bit

(4) is more complex than (3) because
*) both need fragmentation capability in the NSLP
*) both need MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the NTLP
*) only (4) needs setting/processing of a 'DF' bit

it may be that what I understand by (4) is not the same as what you 
are proposing; I'm afraid that can only be fixed by you actually 
defining what you are proposing in a form which other people
can understand and evaluate. however, a pre-emptive point:

if you are proposing a solution which allows *some* NSLP (i.e. not
the one you are interested in, but someone else's) to generate a
message that would need NTLP fragmentation, then I believe that the
consequence is that *all* NTLP implementations will have to support
fragmentation to be compliant with the standard we write. this is
a general consequence of the "we don't design protocols for closed
environments" attitude (see also the 'I in IETF' comment a few emails
back). In other words, you can't just say 'well, the NSLP I care
about only produces small messages so I won't bother with fragmentation
at all'. 

Other people might like to comment on whether this assumption is
sensible.

cheers,

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2003 09:04
> To: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] yet another attempted summary of fragmentation
> discussion
> 
> 
> Hi Robert
> 
> I do not see how you came to the conclusion in
> (E) that option (4) is the most algorithmically functionally 
> complex of all
> the
> solutions for both layers.
> 
> If a NSLP chooses to use the NTLP fragmentation then the complexity is
> the same as (2) and if a NSLP does not need fragmentation then the
> complexity
> is actually reduced.
> 
> I am still in favour of option (4).
> 
> Best regards,
> Georgios
> 
> ----- Original Message -----
> From: "Hancock, Robert" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 18, 2003 12:32 AM
> Subject: [NSIS] yet another attempted summary of 
> fragmentation discussion
> 
> 
> > Dear all,
> >
> > Here is another attempt to summarise the fragmentation issues
> > (for those who are still following).
> >
> > We have basically the same 4 options on the table:
> > 1. Leave it up to the IP layer
> > 2. Do it only in the NTLP
> > 3. Do it only in the NSLP (NTLP provides information about how
> > big fragments are allowed to be)
> > 4. Combination of (2) and (3) - how a message is treated depends
> > on a flag in it (for example).
> >
> > Arguments basically revolve around on concerns about the complexity
> > and processing burden on the NTLP at nodes which wouldn't otherwise
> > have to worry about fragmentation.
> >
> > Some factoids (the most interesting/controversial ones only):
> > A) There are enough trivial/minor/annoying/insuperable concerns
> > about relying on IP level fragmentation to rule out (1).
> > B) For all the others, PMTU discovery has to be done at least
> > at the NTLP level. For (3) and (4) it has to be done at the
> > NSLP level as well (so there is some additional error handling
> > needed in the NTLP).
> > C) It's possible to implement the fragmentation so that reassembly
> > is only needed at the destination NSLP node (whichever layer it
> > actually takes place in). So, the processing cost we are 
> moving around
> > relates only to the fragmentation part.
> > D) I believe that the processing cost tradeoff between (2) and (3)
> > is just as likely to favour (2) as (3) so far as the 'vulnerable'
> > NTLP node is concerned, and favours (2) for the other nodes on the
> > path (see separate emails), especially when interactions 
> with bundling
> > are taken into account. I certainly don't believe the 'fragmentation
> > is obviously expensive' argument.
> > E) (4) is the most algorithmically functionally complex of all the
> > solutions for both layers.
> > F) Fragmentation itself as functionality is not complex (it takes
> > about 5 pages to describe the BSD code for IP in its full glory in
> > Stevens).
> > G) Fragmentation amplifies message loss rates. If you think that
> > message loss is a problem, then fragmentation makes it a 
> bigger problem;
> > however, if you think that message loss is a problem, you probably
> > believe in some kind of recovery (retransmission), which solves
> > the problem anyway.
> >
> > As might come across, I'm still a fan of (2) as a resolution of the
> > argument; I certainly don't see many stones left un-turned in the
> > discussion so far.
> >
> > I'd like to move on to the next open issue (congestion and 
> flow control,
> > IMHO much more tricky and interesting). Any ideas on how to do that
> > sooner rather than later?
> >
> > cheers,
> >
> > 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: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Jun 2003 11:29:03 +0200

Hi Robert

First of all I do not know how you could deduce that I am interested in a
protocol that can be used
 for closed environments and not for the Internet!!!!!!. This is not
true!!!!!!
I am interested in a protocol that can be used for QoS signaling in a RAN
used for third generation
mobile systems. See section 10.4 in the NSIS requirements draft.
This scenario, and are plenty of other scenarios, imposes strict
requirements in terms of processing delays
and scalability (performance of the network does not deterirates badly when
the number of supported users
is increased).

NSIS can be used in such scenarios only if these strict requirements are
met.

Now assume that your option (2) is used:
* the NTLP will have to find out, thus process even if the NSLP does
   not need fragmentation, if fragmentation is needed;
* the NTLP will have to find out, thus process even if the NSLP does not
need
  fragmentation, if reassembly is needed.

Now assume the following  option (3bis) is used : The NSLP and NTLP do not
do fragmentation at all.
In case of an error, e.g., if fragmentation is needed then the NTLP will
send an error message back
to the sender.
When no fragmentation is needed then this option is the fastest and less
complicated.

I am in favour of combining the above two options (by using a "Do
fragmentation" bit) then:
* the NSLP's that do not need NTLP fragmentation will use the above option
(2)
* the NSLP's that do need  fragmentation will use the above option (3bis).

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Georgios Karagiannis'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 18, 2003 10:38 AM
Subject: RE: [NSIS] yet another attempted summary of fragmentation
discussion

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Jun 2003 11:29:03 +0200

Hi Robert

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Georgios Karagiannis'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 18, 2003 10:38 AM
Subject: RE: [NSIS] yet another attempted summary of fragmentation
discussion