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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 18 Jun 2003 10:43:19 +0100

hi georgios,

it's good to see you haven't run out of '!'.

[snip]
> 
> 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;
OK, let's call this 'processing cost A'

> * the NTLP will have to find out, thus process even if the 
> NSLP does not need fragmentation, if reassembly is needed.
reassembly can always be deferred to the node where the 
receiving NSLP is located where reassembly will be needed whichever
layer it is done in. so i don't see this as an issue.

> 
> 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.

forgive me, but I am baffled by this. isn't the processing you
are describing here exactly the same as 'processing cost A' you
object to above? you have to do the error processing first, since
there is no robust way for an NSLP to determine in advance that
fragmentation is not needed.

it would also help if you could explain what you are trying to eliminate -
the code complexity or processing cost (or both). My conclusion which you
originally objected to was about the former (there is a separate conclusion
about the latter, which is basically 'not clear either way'.)

> 
> 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

cheers,

robert h.

PS is 3bis != 4?

> 
> 
> ----- 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
> 
> 
> > 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
> >
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Jun 2003 14:00:45 +0200

Hi Robert

> it's good to see you haven't run out of '!'.

Sorry, couldn't help it :-)

> fragmentation is not needed.

Maybe the application(s) running above NSLP can determine that.
Error processing will be done only when fragmentation is required and
the NTLP is not able to do it.
Thus "processing cost A" is done only when needed, while in option (2)
it is done always.
So by optimizing the situation where fragmentation is not needed, you will
increase the performance of the NSIS protocol.
Note that that the performance of the NSIS protocol will not be affected
when a combination of 2 and 3bis is supported by NSIS and
during a NSIS session the fragmentation option (2) is used.

> about the latter, which is basically 'not clear either way'.)

No, see above

> PS is 3bis != 4?

2 = your 2;
3 bis !=  your 3;
=> my 4 != your 4

Best regards,
Georgios

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 18 Jun 2003 15:49:15 +0200

Hi Georgois,

> Sorry, couldn't help it :-)

Ok, let's go to the end of the road.

> Thus "processing cost A" is done only when needed, while in option (2)

ok, I agree. But I don't think A costs too much. If (2) is done: NTLP
compare the length of NSLP message with the MTU value which is determined by
PMTUd. If  NTLP doesn't do the comparaison, NSLP must do it. There is no
difference.

On the other hand, if NSLP and NTLP support fragmentation, both of them must
do PMTUd. If NSLP know its message's length (NSLP message's length) is
small, NTLP can know it too. NTLP know exactly the length of the whole
message  ( header, some complementary objets of NTLP). Of course, two PMTUds
are not identical, PTMUd_NSLP is E2E, PTMUd_NTLP is hop by hop (supposing
that all node are NSIS aware). BTW,  the PTMUd must be done.

If NTLP sees that it's not necessary to fragment a message, it sets bit
"Don't fragement" by itself and the intermediate NTLPs won't do
framgementation anymore and don't need to examine the message's length. But
the scope of NTLP is adjacent hops. How can NTLP can know the length of  a
message is small in  the end-to-end scope ?  It seems that you're right,
Georgios.

I thinks ( I take the RSVP as an exemple), NSLP_RSVP send message PATH from
A to B, NTLP has the right to fragment the message. When A receive the
message RSVP from B, NSLP of A know the MTU of a packet A to B (end to end).
If A send a another message to B and the length of message is smaller than
MTU, it can set the bit "Don't Fragment" and the NTLP on the intermediate
nodes won't do fragmentation anymore. If we do it, there is a problem that
if the route changes and the MTU is not correct anymore, we must have some
messages for errors.

> => my 4 != your 4

What's your 4bis ?

Nary Tra
ENST, Paris.

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 19 Jun 2003 15:02:52 +0200

hi Robert,

I still don't see that it is more useful in the case NSLP can do the
fragmentation :

+ Let NSLP do fragmentation is advantageous only in the case NSLP is not
installed on NTLP in a node. For another application such as reservation
IntServ, it's not useful because the fragmentation is redone by every node
on the data path anyway. (if NSLP_applic1 of a node A sets a bit Don't
Fragment (DF=1), NSLP_applic1 of a intermediate node C can unset this bit
(DF=0) because node C can change the message.)

+ if NSLP do fragmentation, the implementation may have to be redone for
each signaling application (NSLP).

+ It becomes hard to share PMTU information between different NSLPs. For
exemple, a end host A want to implement NSLP for QoS (NSLP_QoS) and NSLP for
Middlebox (NSLP_Mid) with the same end host B, NSLP_QoS and NSLP_Mid must do
PMTUd.

I think it's better if NTLP do fragmentation and it's capable of doing PMTUd
end-to-end. Just a proposition.

Nary Tra
ENST, Paris.

---

From: Roland Bless <[email-masked]>
Date: Tue, 24 Jun 2003 18:49:23 +0200

Hi Georgios,

please see comments inline.

> Thus "processing cost A" is done only when needed, while in option (2)

Sorry, but with respect to robustness I fully disagree here. Even if you
have this "Don't fragment" bit set, an NTLP implementation has to
perform the check whether the PDU will fit into an MTU on the outgoing
link. If this is however not the case, you have to send an error message
back. So you have to check this anyway, like in this incomplete
pseudo-code:

if ( length(PDU) <= MTU(outgoing_link) )
  forward(PDU,outgoing_link)
else { // msg too big
  if (DF_bit_is_set(PDU)) 
    send_errormsg_back(PDU); // msg too big and dont fragment bit set
  else
    do_fragmented_forward(PDU,outgoing_link); // fragmentation allowed
}

[I guess John is right: this is really not related to the framework,
but to protocol design...:-)]
Avoiding the first if()-check always when the DF-bit is set will be 
broken (what do you do in case the NSLP did not use the correct size 
or the link suddenly changes and the PathMTU is no longer valid?).

> increase the performance of the NSIS protocol.

Though I'm not against the DF-bit, I still don't see any performance
advantages from it as you state. Your DF-bit assures only that
fragmentation will not occur "silently". So the DF-bit is usefull in
cases when you want to avoid fragmentation at all (which may have
performance implications). In case the NTLP PDU is always small enough
the do_fragmented_forward() will never be called anyway. With respect to
reassembly: It is fairly easy to check for a "Last Fragment" bit (that
is set for non-fragmented PDUs, too) so that you don't have to wait
until further fragments arrive.