Subject: RE: [Tsvwg] SCTP and IP Frag aliasing on LFNs ?

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 26 Feb 2002 12:57:38 -0800

Randy,
Hi. I do come up with different numbers, and they are
very different from yours so please double check
me on them. Sorry I didn't include them initially.

Using your parameters:
  link-rate = 1 Giga-bit-per-sec
            = 100,000,000 bytes-per-sec (approx)
  RTT = 300ms
  MTU = 500 bytes

I come up with:
  bytes-per-ms = bytes-per-sec / 1000
               = 100,000,000 / 1000
               = 100,000 bytes-per-ms

  packets-per-ms = bytes-per-ms / MTU
                 = 100,000 / 500
                 = 200 packets-per-ms

  packets-in-pipe = packet-per-ms * RTT(ms)
                  = 200 * 300
                  = 60,000 packets in pipe
                    IP-ID doesn't wrap in the pipe

And at 10 Gbps (10x):
  600,000 packets in pipe
  IP-ID wraps 9.15 times in the pipe

And at 100 Gbps (100x):
  6,000,000 packets in pipe
  IP-ID wraps 91.5 times in the pipe

And yes it would be the same issue for any transport
that relies on IP (v4) fragmentation.

So I stil have questions about this issue in general.
Is it going to be an actual problem in the
forseeable future (even for smaller RTTs in the
50ms range), or are there other mitigating factors
that make it a non-issue?

Thx again,
Jim

P.S. Another way to calc this is:
  pipe-distance-in-sec = 300ms = 0.3 sec

  bytes-in-pipe = bytes-per-sec * pipe-distance-in-sec
                = 100,000,000 * 0.3
                = 30,000,000 bytes-in-pipe

  packets-in-pipe = bytes-in-pipe / MTU
                  = 30,000,000 / 500
                  = 60,000 packets-in-pipe (on 1Gbps link)

---

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 4:05 AM
> To: WENDT,JIM (HP-Roseville,ex1)
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP and IP Frag aliasing on LFNs ?
> 
> 
> Jim:
> 
> Some thoughts below...
> 
> "WENDT,JIM (HP-Roseville,ex1)" wrote:
> > 
> > Based upon following in RFC-2960:
> > 
> > > 6.9 Fragmentation and Reassembly
> > >   Note: Once a message is fragmented it cannot be re-fragmented.
> > >   Instead if the PMTU has been reduced, then IP 
> fragmentation must be
> > >   used.  Please see Section 7.3 for details of PMTU discovery.
> > 
> > > 7.3 Path MTU Discovery
> > >   4) Since data transmission in SCTP is naturally 
> structured in terms
> > >      of TSNs rather than bytes (as is the case for TCP), 
> the discussion
> > >      in Section 6.5 of RFC 1191 applies: When retransmitting an IP
> > >      datagram to a remote address for which the IP 
> datagram appears too
> > >      large for the path MTU to that address, the IP 
> datagram SHOULD be
> > >      retransmitted without the DF bit set, allowing it to 
> possibly be
> > >      fragmented.  Transmissions of new IP datagrams MUST 
> have DF set.
> > 
> > Am I correct in understanding that IP fragmentation can occur
> > on SCTP packets across a IPv4 PMTU degrade, and that worst case,
> > IP fragmentation can occur for all packets in flight up to the
> > roundtrip pipe size between the sending endpoint and the last
> > hop router?
> > 
> I would think this can occur for any transport doing  PMTU discovery.
> I do have  a hard time envisioning a very very highspeed inter-net
> link that has a PMTU event without some sort of accompanying routing
> re-convergence. And it seems to me if you hit a routing reconvergence
> you are in for at LEAST 1 timeout putting you way back in slow start.
> 
> But lets do some rough calculations on a napkin anyway and see what
> happens if a PMTU change occurs on say a 1 Gig-a-bit link with
> lets say a 300ms round trip time. And just for fun we will assume
> you are the ONLY user on this 1 Gig-a-bit link and you have fast
> machines on both sides that can use it all.
> 
> Now lets say a 1500 byte MTU before the change and a 500 byte
> MTU after the change. Now on a napkin, I come up with about 6.7
> packets per ms... so we show up with 2,010 packets in flight.
> 
> Note I am rounding here a 1,000,000,000 bit -> 100,000,000 Mega Byte.
> This may not be exact but it is quite close and allows for the
> overhead in the e-net and anthing else :>
> 
> Now if I have only 2,010 packets all that need to be resent 
> and with an
> IP id of 16 bits or 65,535 I should be ok.. 
> 
> In fact I should be ok up to a RTT time of about 4.8 seconds.
> -----
> 
> Now lets look at the same case with a 10 Gig a bit link.
> We jump by a factor of 10 so... 
> 
> 20,100 packets in flight .. no problem... 
> 
> Good up to 480ms round trip time..
> 
> So I guess there may be an issue if one has greater than a 480ms
> round trip time and a 10 gigabit connection where you are using
> the whole link all by yourself.
> 
> > If so, and the pipe is large, has there been any discussion or
> > concern regarding aliasing or wrap-around of the 16-bit
> > Identification (ID) field in the IP header?  Is this an
> > issue, and if so, how is it being addressed?
> > 
> 
> Considering that the scenario is quite far fetched in todays
> technology over an inter-net. Maybe in a Intra-net.. but then
> one would hope you would not get more than a 400ms RTT...
> 
> And besides all that .. in the future if this really becomes
> a problem I think SCTP is exandable enough that we can figure
> out a new chunk or some such to help with this type of situation.
> 
> I think we can worry about this problem when we get a bit closer
> to having a realistic scenario where a problem would exist...
> 
> I just don't see it yet... 
> 
> Maybe I have missed something in my back-of-the napkin calculations
> or I am mis-interpreting what circumstances you are envisioning. If
> so please correct me..
> 
> 
> R
> 
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Feb 2002 18:44:03 -0600

JIM,

The RFC requires an implementation to chunk down DATA chunks
to fit into a path MTU, but AFAIK there is no requirement
stopping an implementation from chunking down DATA chunks to
less than a path MTU and then bundling them back up.  Our
implementation, for example, splits DATA chunks to 1/2 PMTU or
less.  This mitigates falling MTUs in that they must fall
faster (and smaller) to cause fragmentation on retransmission.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦