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

From: [email-masked]
Date: Thu, 12 Jun 2003 11:56:19 +0200

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: [email-masked]
Date: Thu, 12 Jun 2003 12:54:14 +0200

Hi Robert,

OK. Then I guess this means three things:
- NTLP needs to support fragmentation (for the NSLPs that don't want to do
it)
- NTLP does not need anything else to support option 4. I guess we could
add a sentence saying that NSLP is allowed to do its own fragmentation but
that this is transparant to NTLP
- NSLPs seeking to do fragmentation themselves need to address the MTU
discovery issue.

Is this a reasonable position for the framework to take?
Sven

"Hancock, Robert" <[email-masked]> on 12/06/2003 12:06:21

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    "[email-masked]'" <[email-masked]>
Subject:    RE: [NSIS] attempted summary of fragmentation discussion

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

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

---

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

hi sven,

i agree with your first two points. 

at the moment, i am not sure on the justification for the third and so would
prefer to defer it - it sounds like feature-itis to me.

r.

> Sent: 12 June 2003 11:54

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 13 Jun 2003 16:02:49 +0100

hi melinda,

i agree with you that the reassembly is the critical part of the
overall packet handling problem. looking back over the v6 discussions
on this topic, key parts of the argument are much more about 
reassembly costs and doing fragmentation in a way to minimise
them, rather than the costs of fragmentation themselves.

however, i think it is possible to implement fragmentation so that
reassembly is only required in the NSLP node where the message has
to be dealt with. this will be true however we split the layering
issues up, and so doesn't affect the decision we are trying to make.
(this is not the case with the fragmentation stage, where at least
part of the argument is that doing fragmentation in the NTLP may
overload a node which doesn't actually care about the corresponding
application.)

robert h.

i didn't want to confuse the argument by including bundling, but
in the performance analysis there is a sort of interaction. the analysis 
considers only a single big message after all.

> From: Melinda Shore [mailto:[email-masked]]
> Sent: 13 June 2003 15:53
> To: Hancock, Robert
> Cc: [email-masked]
> Those are good points, but I think what's missing from that
> analysis is the reassembly costs, which would tend to
> dominate the process (as opposed to fragmentation costs,
> which are low).  When talking about reassembly you have to
> consider what happens when packets arrive out-of-order, are
> dropped, etc., and that means additional buffers
> (statefulness), additional timers (more statefulness), and
> additional execution logic.
> 
> The other problem, I think, is that the problem isn't
> bundling, it's message size, and that's almost certainly
> going to be an issue whether application messages are
> bundled or not.
> 
> Melinda
>

---

From: "Daniel Warren" <[email-masked]>
Date: Fri, 13 Jun 2003 10:48:00 +0100

I'm going to take on more run at this...

I can see no usefulness of a 'Do not fragment bit'.  The fragmentation of
messages is something that only takes place to ensure that a message that
would otherwise not make it across a network because of it's unfragmented
size, actually does make it from one end to the other.  If a message results
in the packet being sent being greater than the MTU for one hop of the path
the message takes and the message cannot be fragmented it is a guarantee
that the message will fail to be communicated and an error will be returned
to the sending node.  If fragmentation is allowed there is still a
possibility that the message will fail (should one of the fragments get
lost) but there is also a possibility (and one would hope, a significantly
high one) that the messgae will be delivered successfully.

So, by setting a 'Do not fragment bit' you are basically increasing the
likelihood of messages not being delivered successfully.  If the bit is set,
and the message arrives at the receiving end unscathed, that has nothing to
do with the bit being set, since the message would have to be under the size
of the PMTU and so would not have been fragmented anyway!  I can understand
the concept of the bit if you want to ensure reliable delivery of the
message for some reason, but that could just as easily be provisioned for by
wetting the MTU size on the hops that are going to have to handle the
messages to be big enough not to have to fragment the messages.  That puts
you back in the situation above where the bit would make no difference.

The only other consideration would then be bundling of messages that would
result in the NTLP fragmenting a number of messages that are being sent in
an amalgous blob.  If a message not to be fragmented gets in amongst a
bundle of other messages and the bundle results in something larger than
PMTU being sent, that *could* justify a 'Do not segment' bit.  However,
wouldn't a better solution be a 'Do not bundle' bit?

Dan

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]]
Sent: 12 June 2003 13:03
To: Hancock, Robert; [email-masked]
Subject: Re: [NSIS] attempted summary of fragmentation discussion

Hi Robert

I proposed many solutions to this in previous e-mails.
The main advantage of having this feature is that the performance of the
node in terms of processing delays will be enhanced
when the node does not have to perform fragmentation.

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Georgios Karagiannis'" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 12, 2003 1:50 PM
Subject: RE: [NSIS] attempted summary of fragmentation discussion

> hi georgios,
>
> how and why?
>
> i.e. it would be helpful (at least to me) if you could
> a) define (4) in a bit more detail about how the layers and nodes would
> interact to achieve it, and
> b) explain why this functionality would justify the additional complexity.
>
> cheers,
>
> r.
>
> > From: Georgios Karagiannis [mailto:[email-masked]]
> > Sent: 12 June 2003 12:37
> > To: Hancock, Robert; [email-masked]
> > Hi Robert
> > Please combine (3) and (4) in a more strict way!
> >
> > Best regards,
> > Georgios
> > ----- Original Message -----
> > From: "Hancock, Robert" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, June 12, 2003 11:21 AM
> > > *) make the NTLP do fragmentation when it is needed;
> > ideally, do it in
> > such
Bracknell,
confidential to
> permission. This communication is for information only and shall not
create or