Subject: RE: [rddp] IPsec & Markers

From: "Culley, Paul" <[email-masked]>
Date: Fri, 8 Oct 2004 13:28:05 -0500

> >>
> > The Markers are to enable the receiving side to locate the start of 
> > MPA Frames even when TCP Segments are received out-of-order.
> 
> Out of order or "unaligned"?  When the entire FPDU fits in 
> the TCP segment (e.g. aligned), I have no problem locating 
> the start of MPA Frames, in (TCP sequence) order or not.
> 
Unfortunately, just because an FPDU might fit in a TCP segment, does not
mean that it MUST always be aligned.  It is legal (but unwise) for a
sender to segment the TCP stream at other than FPDU boundaries.

> > Even with IPSEC enabled a received out-of-order TCP Segment is not 
> > necessarily an MPA Frame.  Without markers how would the receiver 
> > locate the MPA Frame boundary?
> 
> Sec 5.3 says "MPA MUST encapsulate the ULPDU such that there 
> is exactly one ULPDU contained in one FPDU."  With IPsec, 
> there will be no middlebox that can re-segment TCP segments.  
> What I put in the IPsec
> (e.g.) tunnel will come out the other end of the tunnel.
> 
> MikeC
Same comment as above, while ULPDU (i.e. DDP segments) must fit exactly
into FPDU, there is no absolute requirement that FPDUs must fit exactly
into TCP segments.
> --

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

---

From: "Michael C. Cambria" <[email-masked]>
Date: Fri, 08 Oct 2004 15:00:09 -0400

> sender to segment the TCP stream at other than FPDU boundaries.

Agreed.  In fact, this happens all the time with an MTU change (e.g. 
jumbo to 1500).  An unacked TCP segment that once fit in an entire FPDU 
now needs to be retransmitted in many TCP segments.

On the receive side, until I have the entire FPDU, so as to calculate 
the CRC, regardless of what order these TCP segments arrive in I can't 
do much with the data.

In general, (to simplify) a receiver can take any given TCP segment, use 
the "length" to find the CRC.  If the CRC doesn't match, I don't have an 
FPDU.

Regards,
MikeC

-- 
Michael C. Cambria

email : [email-masked]
  VoIP : sip:[email-masked]
   FWD : sip:[email-masked]

---

From: Michael Krause <[email-masked]>
Date: Fri, 08 Oct 2004 12:43:51 -0700

I hate to bring this up but from a process perspective, did we not already 
achieve consensus that markers would always be required?  We are getting 
towards last call so it would be good to avoid re-opening a topic if it has 
already reached consensus.

Mike

At 12:00 PM 10/8/2004, Michael C. Cambria wrote:

>Culley, Paul wrote:
>
>>>>The Markers are to enable the receiving side to locate the start of MPA 
>>>>Frames even when TCP Segments are received out-of-order.
>>>
>>>Out of order or "unaligned"?  When the entire FPDU fits in the TCP 
>>>segment (e.g. aligned), I have no problem locating the start of MPA 
>>>Frames, in (TCP sequence) order or not.
>Agreed.  In fact, this happens all the time with an MTU change (e.g. jumbo 
>to 1500).  An unacked TCP segment that once fit in an entire FPDU now 
>needs to be retransmitted in many TCP segments.
>
>On the receive side, until I have the entire FPDU, so as to calculate the 
>CRC, regardless of what order these TCP segments arrive in I can't do much 
>with the data.
>
>the "length" to find the CRC.  If the CRC doesn't match, I don't have an FPDU.
>
>Regards,
>MikeC
>
>--
>Michael C. Cambria
>
>email : [email-masked]

---

From: "Michael C. Cambria" <[email-masked]>
Date: Fri, 08 Oct 2004 22:51:02 -0400

Michael Krause wrote:

> 
> I hate to bring this up but from a process perspective, did we not 
> already achieve consensus that markers would always be required?  We are 
> getting towards last call so it would be good to avoid re-opening a 
> topic if it has already reached consensus.

The WG only agreed to make IPsec mandatory to implement in San Diego (2 
months ago).  I never suggested anything other than being able to do for 
markers what one can do for CRC when running over IPsec.

MikeC

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 9 Oct 2004 06:09:03 +0200

On Oct 8, 2004, at 9:43 PM, Michael Krause wrote:

> already
> achieve consensus that markers would always be required?  We are
Agreed.

The optimization that has been suggested is that MPA Mode bits be
allocated to deal with the case where both ends have an MPA-Aware
IPSEC implementation and that the MPA layer is aware the IPSEC is
being used (reliably) and the IPSEC mode is such that all PMTU
changes will be hidden by IPSEC (i.e. the virtual path's PMTU
will never change).

Not only do I think the above scenario is unlikely, but if your
platform is doing IPSEC in the same device as RDDP/RDMAP
and MPA/TCP then why are you worried about the CPU overhead
of calculating markers?

In my estimation for every 100 connections where this condition
could apply the "savings" would be significant for at most one.
More importantly there will be billions of  connections where
these option bits are totally irrelevant.

---

From: "Somesh Gupta" <[email-masked]>
Date: Sat, 9 Oct 2004 13:28:19 -0700

David,

As far as MPA is concerned, a lot of the discussion
held previously was under the context of an
experimental draft.

My assumption is that if it is changes to go on
the standards track, it would be entirely open
for another round of discussions.

Looking forward to your comments on the topic.

Thanks,
Somesh

---

From: Sukanta ganguly <[email-masked]>
Date: Tue, 12 Oct 2004 07:43:54 -0700 (PDT)

Hi,
  Do we need another draft for finalizing the IPSec &
Marker discussion. We have had a lot of discussion but
seems like no conclusion is beingh made. We keep on
revisiting this topic multiple times.
  It definitely is time to  put a formal, agreeable
statement resolving this issue so that we can all
conclude happily.

Thanks
SG

> Looking forward to your comments on the topic.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 12 Oct 2004 11:12:44 -0500 (CDT)

> statement resolving this issue so that we can all

If a bit were worth adding, it would have the following
meaning:

1) The side setting the bit has an MPA-Aware IPSEC
   implementation.  Hence each IP Datagram submitted
   to IPSEC for this connection would contain only
   whole MPA Frames.
2) That in its interface with the local IPSEC stack
   it will be aware of the original TCP Segment boundaries,
   and that nothing in the local stack will disturb them.
3) That if this bit is set by the other side, then this
   side does not want Markers sent to it.

The last point in particular strikes me as unlikely.
If your peer does not have MPA thru IPSEC tightly
integrated you will want markers.  Therefore you have
to have the logic to process them.

This is a major contrast with the normal marker suppression,
which is intended to support receivers who did not want to
deal with Markers at all.

Markers are ugly, and they add code/gate complexity.  But
they aren't all that computationally intensive.  If you have
the code/gates to implement them, and you even have number
crunching capacity to intergrate IPSEC, then why do you need
to suppress receiving markers *if* and only if an "alignment-
maintaing IPSEC tunnel" can be validated to exist?

The sender already MUST support generating or not generating
them.  The existing bit was justified by allowing some
implementations to totally avoid processing markers on
receive when they in fact had no use for them.

But using up another option bit for this just doesn't
strike me as worthwhile.  You do run out of them eventually.

--
Caitlin Bestler
http://asomi.com/