headers
Brian F. G. Bidulock | 1 Aug 2002 01:58
Favicon

Re: SCTP:flight size

Randall,

If FR marks for retransmission but doesn't reduce
flight size then (1) below is incorrect.

> > > 1) They are NOT marked for retransmission

--brian

On Wed, 31 Jul 2002, Randall Stewart wrote:

> What does FR and bursts have to
> do with flight size?
> 
> If you FR something it remains in flight. If you recoginize
> it as needing FR but can't due to a cwnd limit.. its
> back to being marked for retransmission... in effect the FR
> marks it for retransmission and then you try to send...
> 
> I don't see any ambiguity here..
> 
> R
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Randall,
> > 
> > What about FR and bursts?
> > 
> > --brian
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 1 Aug 2002 02:06
Favicon

Re: SCTP RTT measurement question.

David,

Good point.  HEARTBEAT RTT calulcations do no include SACK
delays.  It appears that when failing over from a primary
destination to a secondary, the secondary could have a more
agressive RTO than should be expected if the peer is delaying
SACKs.  This could result in excessive retransmissions for a
period immediately after the failover: which, of course, is
the worst time to be having excessive retransmissions.

There is a case for loadsharing over avialable destinations.

--brian

On Wed, 31 Jul 2002, David Lehmann wrote:

> Vern Paxson wrote:
> 
> >>What if we used one of the unused bits of the chunk flags in the DATA
> >>chunks to tell the receiver to "sack the packet containing this DATA
> >>chunk without delay"?  Then we could get more accurate measurements.
> >>
> > 
> > The point of measuring RTT is not to measure the network-layer round trip
> > time, but to estimate how long it takes to get feedback for a transmitted
> > data packet.  For that use, the RTT *should* include delays such as delayed
> > acknowledgements, because that's part of what contributes to the overall
> > feedback delay.
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laurent Glaude | 1 Aug 2002 14:46
Favicon

Re: SCTP RTT measurement question.

I see this as two situations:

(1) - In the case of steady traffic, then the 200ms delay incurred by 
the delayed ack timer seldom occurs, because instead a sack is sent for 
every two data packets received (and the packets come in quickly). Thus 
RTT measurements from data packets and heartbeats are bound to give a 
comparable result.

(2) - In the case where the 200ms expires frequently, I don't see a 
problem for the reason that the traffic is very, very low (ie with 200ms 
delayed ack, it means 5 packets or less per second ).

-Laurent

Brian F. G. Bidulock wrote:
> David,
> 
> Good point.  HEARTBEAT RTT calulcations do no include SACK
> delays.  It appears that when failing over from a primary
> destination to a secondary, the secondary could have a more
> agressive RTO than should be expected if the peer is delaying
> SACKs.  This could result in excessive retransmissions for a
> period immediately after the failover: which, of course, is
> the worst time to be having excessive retransmissions.
> 
> There is a case for loadsharing over avialable destinations.
> 
> --brian
> 
> On Wed, 31 Jul 2002, David Lehmann wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Stewart | 1 Aug 2002 15:03
Picon
Picon

Re: SCTP:flight size

Any time you mark something for retransmission it
is no longer considered in the network... In the
case of PR-SCTP you mark it for skipping INSTEAD
of marking it for retransmission. Thus it to
is considered not in flight...

R

"Brian F. G. Bidulock" wrote:
> 
> Randall,
> 
> If FR marks for retransmission but doesn't reduce
> flight size then (1) below is incorrect.
> 
> > > > 1) They are NOT marked for retransmission
> 
> --brian
> 
> On Wed, 31 Jul 2002, Randall Stewart wrote:
> 
> > What does FR and bursts have to
> > do with flight size?
> >
> > If you FR something it remains in flight. If you recoginize
> > it as needing FR but can't due to a cwnd limit.. its
> > back to being marked for retransmission... in effect the FR
> > marks it for retransmission and then you try to send...
> >
> > I don't see any ambiguity here..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 1 Aug 2002 19:23
Picon
Favicon

Re: Re: HighSpeed TCP for Large Congestion Windows

Sally Floyd wrote:
> Reiner -
> 
> 
>>I have few comments about that draft ...
>>
>>1. I'm not convinced that this is a real problem for the (public) Internet:
> 
> 
> As I said in the viewgraphs, I certainly don't think this is a
> pressing problem in the Internet today, for anyone.  The HighSpeed
> TCP draft tried to be clear about the problem description, which
> is the *very* small packet drop/mark rates needed to sustain very
> high congestion windows with current TCP.  
> 
> The reason to bring this to tsvwg is exactly to hear whether people
> feel this is inappropriate to bring to the IETF, or not.  (My own
> reading of the sense of the working group meeting was that people
> felt that this *was* appropriate to bring to the IETF.)

Hi, Sally (et al.),

My read was somewhat different. While some were interested in exploring 
this (IMO, 'academically'), most felt that because it wasn't of 
near-term utility it was premature for the WG.

My own thoughts, as mentioned at the IETF, are that there are 
interesting aspects to this, but I'm uncomfortable with proposing three 
modifications at once. That either means there's a more fundamental 
problem, or that some of the solutions are marginal, or both.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lili Wang | 1 Aug 2002 20:19
Picon
Favicon

(no subject)


  This message is about the internet draft " A Conservative SACK-based
Loss Recovery Algorithm for TCP".
   We guess that one reason to forbid the recovery algorithm before the
cumuulatively ACK past RecoveryPoint is  to avoid false fast
retransmission. To avoid the problem, we think that it  need to forbid
invoking the algorithm to a further point  beyond what is specified in
the draft(RecoveryPoint).
    In recovery peroid, the sender may send
new data (according to rule(2) in NextSeg()). In this case, 
HighData is above RecoveryPoint. Thus, the data between RecoveryPoint
and HighData have been transmitted in the recovery peroid. If a tomeout
occurs later in the recovery period, the sender begin slow start. Since
the data between RecoveryPoint and Highdata may be already in the
receiver queue, retransmission of those data  may generate duplicate ACKs,
 which may cause false fast retransmission. For example. suppose recovery
point is the right edge of segment n and segment n is lost.
During loss recovery phase, segment n+1, n+2, n+3 have been transmitted
and successfully  received by the receiver. 
A timeout occurs later in the recovery perid and the sender begin slow
start. Segment n, n+1, n+2, n+3, n+4 are (re)transmitted. Receipts
of segment n, n+1, n+2 and n+3 all generate an ACK that tells the sender
to expect segment n+4 (suppose segment n+4 is not in the receiver
queue at that time). Since the  cumulatively acknowledgment has been
beyond the last value of RecoveryPoint, the loss recovery is invoked upon
receipt of enough duplicate ACKs. However, in this case, there is 
no segment loss , it should not invoke the recovery algorithm.

Cheers,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Joe Touch | 1 Aug 2002 20:20
Picon
Favicon

Re: Re: HighSpeed TCP for Large Congestion Windows

Sally Floyd wrote:
>>My read was somewhat different. While some were interested in exploring 
>>this (IMO, 'academically'), most felt that because it wasn't of 
>>near-term utility it was premature for the WG.
> 
> 
>>My own thoughts, as mentioned at the IETF, are that there are 
>>interesting aspects to this, but I'm uncomfortable with proposing three 
>>modifications at once. That either means there's a more fundamental 
>>problem, or that some of the solutions are marginal, or both.
> 
> I think that there are two completely separate fundamental problems.

Limited Slow-Start is related to QuickStart, IMO. Both are methods, 
albeit with different mechanisms, for rapid ramp-up.

[Limited Slow-Start]
 > is a
> separate draft from the HighSpeed draft, however, because it could
> be useful with or without the modified response function of HighSpeed
> TCP.

It is not useful to be able to ramp up to a large window that cannot be 
sustained. These are necessarily related.

> The second fundamental issue, of how to get permission from routers
> for best-effort (or other) traffic to start with a high initial
> window, is in my view quite separate, more long-term (as is
> anything involving modifications to routers) and more controversial.
> I am assuming that the QuickStart draft, which presents one proposal
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sally Floyd | 1 Aug 2002 20:05

Re: Re: HighSpeed TCP for Large Congestion Windows

>My read was somewhat different. While some were interested in exploring 
>this (IMO, 'academically'), most felt that because it wasn't of 
>near-term utility it was premature for the WG.

>My own thoughts, as mentioned at the IETF, are that there are 
>interesting aspects to this, but I'm uncomfortable with proposing three 
>modifications at once. That either means there's a more fundamental 
>problem, or that some of the solutions are marginal, or both.

I think that there are two completely separate fundamental problems.
One is that the current TCP response function requires unrealistically
low packet drop rates to sustain congestion windows of thousands
or tens of thousands of packets.  The second fundamental problem
is that if best-effort connections want to *start* with large
windows, then they need explicit permission from all of the
routers along the path (in my view).

I think these are separate problems, with completely separate time
scales, as I thought I made clear in my presentation.  That is, it
would make sense to me for the HighSpeed TCP draft to be mulled
over and then, in the fullness of time, if it is judged by the
community not to be unduly dangerous and/or unfair, to become an
Experimental RFC, so that more real-world experience can be gathered.

The Limited Slow-Start draft is a small, completely optional proposal
that, in my view, is useful to allow TCP connections to effectively
slow-start up to those very large congestion windows.   It is a
separate draft from the HighSpeed draft, however, because it could
be useful with or without the modified response function of HighSpeed
TCP.  Just a small piece that, in a reasonably simple and low-overhead
(Continue reading)

Permalink | Reply | 2 comments |
headers
stanislav shalunov | 2 Aug 2002 09:17

Re: Re: Limited Slow-Start for TCP with Large Congestion Windows

Mark Allman <mallman <at> grc.nasa.gov> writes:

> I am not familiar with the implementation at all, so I am trying to
> understand this....  My workstation has one route entry --- all
> traffic goes one way.  So, does that mean that all my connections
> share some cached ssthresh value?  That would not seem right to me.

I don't know what OS your workstation is running, but if the stack is
BSD-based, you might have the feature that is being discussed.  On my
ancient FreeBSD laptop, I see this:

shalunov <at> cain$ netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
default            216.254.censored   UGSc       10        1      wi0
127.0.0.1          127.0.0.1          UH          0  3610838      lo0
[Two local Ethernet routes.]

But this doesn't include cloned route entries (which would be
displayed with `netstat -nar').  However, if I look carefully at the
(cloned -- i.e., automatically inserted by the OS on first connection)
route to my mail server, I see this:

shalunov <at> cain$ route -n get mail
   route to: 209.211.239.218
destination: 209.211.239.218
    gateway: 216.254.censored
  interface: wi0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Stewart | 2 Aug 2002 16:16
Picon
Picon

Re: SCTP RTT measurement question.

David Lehmann wrote:
> 
> Vern Paxson wrote:
> 
> >>What if we used one of the unused bits of the chunk flags in the DATA
> >>chunks to tell the receiver to "sack the packet containing this DATA
> >>chunk without delay"?  Then we could get more accurate measurements.
> >>
> >
> > The point of measuring RTT is not to measure the network-layer round trip
> > time, but to estimate how long it takes to get feedback for a transmitted
> > data packet.  For that use, the RTT *should* include delays such as delayed
> > acknowledgements, because that's part of what contributes to the overall
> > feedback delay.
> 
> This makes sense for a single homed endpoints like TCP.  However, I am
> questioning the logic for multihomed endpoints.
> 
> e.g. If I have a peer endpoint with four destination IP addresses,
> all of which run through four equal networks, I should have similar
> SRTT values for all destinations.  So, when switching destinations
> for the DATA, either for failover, retransmit, or user request, the
> RTO calculation should produce a similar value for the new
> destination as it did for the old.
> 

It is true that the RTO estimate may be off by 200ms on the
primary destination as compared to the HB'ing 3 idle destinations.. but
the real question is will 200ms make any difference and does it matter?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane