Subject: [Tsvwg] Re: Draft-floyd-ecn-alternates-00.txt

From: Sally Floyd <[email-masked]>
Date: Mon, 16 May 2005 13:17:56 -0700

>2) Alternatively, a different behaviour may arise if a router remarked:
>01 -> 10 or 10 -> 01
>This seems a potential candidate for another behaviour, possibly to signal
>something (less than normal congestion, or at least different to 11) to an
>end host. This remarking doesn't ensure a a full congestion response as in
>11. If however "ECN-NONCE" were used at the end-hosts, this remarking would
>be interpreted as congestion signalling - safe for the network, but perhaps
>an expected (more severe) outcome.

And you are right, this one would need a note.

If the sender is signalling the use of alternate semantics, then this
one should not be a problem.

The problem would occur if this was done on a packet where the
sender was using the default ECN semantics.  In this case, the 
sender might interpret this as a receiver lying when it reports
that the packet was not ECN-marked, because the receiver can't
return the correct nonce that verifies that the packet in fact
wasn't ECN-marked. So if the router remarks 01 -> 10 or 10 -> 01,
the router should be *quite* sure that the packet comes from a sender
that is using the alternate ECN semantics.

Yes?

- Sally

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 17 May 2005 11:59:18 +0100

> one should not be a problem.
I agree.

> that is using the alternate ECN semantics.
Yes! - Otherwise it should use the default of drop or remark to '11'.

---

From: Subhashini <[email-masked]>
Date: Tue, 17 May 2005 11:21:34 +0530

Hi All,

When Heartbeat is enabled:
==================
  Whenever any data chunk is transmitted, T3-rtx timer is started, if 
not running already. When we fail to get SACK for the data chunk, it is 
marked for retransmission and error counter is incremented. Also, we 
reset this error count, whenever any SACK or Heartbeat Ack is received. 
If no SACK or Heartbeat Ack, once the error counter reaches the maximum 
value, communication lost notification is given to the peer and 
association is closed. In this case, suppose Heartbeat/Heartbeat Acks 
are exchanged without fail and if data chunks are not unacknowledged, 
upper layer will not be notified and there will not be any change in the 
association state. What is the other possibility to find out the 
unacknowledgement of data chunks and closing the association? Do we need 
to assume that, if the peer is able to acknowldge the heartbeat, it 
should be acknowledging the data chunk also?

When Heartbeat is not enabled:
=====================
In this case, since only the SACK is the only way of acknowledging the 
data chunk, the error counter will reach the maximum value and close the 
association.

Please clarify.

thanks,
Subhashini ...

---

From: Ted Faber <[email-masked]>
Date: Tue, 17 May 2005 11:56:25 -0700

> When Heartbeat is enabled:
[...]
> Please clarify.

You first.

Supplying some context would help someone who isn't you answer your
question.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 May 2005 21:06:32 +0200

Hi Subhashini,

see my comments in-line.

Best regards
Michael

On May 17, 2005, at 7:51 AM, Subhashini wrote:

>  Whenever any data chunk is transmitted, T3-rtx timer is started,  
> if not running already. When we fail to get SACK for the data  
> chunk, it is marked for retransmission and error counter is  
> incremented. Also, we reset this error count, whenever any SACK or  
> Heartbeat Ack is received. If no SACK or Heartbeat Ack, once the  
> error counter reaches the maximum value, communication lost  
> notification is given to the peer and association is closed. In  
> this case, suppose Heartbeat/Heartbeat Acks are exchanged without  
> fail and if data chunks are not unacknowledged, upper layer will  
> not be notified and there will not be any change in the association  
> state. What is the other possibility to find out the
That is correct. But the SCTP implementation on the receiving side is  
broken if it responds
to HB with HB-ACKs but does not send SACK in response to DATA chunks.
> unacknowledgement of data chunks and closing the association? Do we  
> need to assume that, if the peer is able to acknowldge the  
> heartbeat, it should be acknowledging the data chunk also?
This is the correct behaviour. If you want more, you need application  
level heartbeats...
> In this case, since only the SACK is the only way of acknowledging  
> the data chunk, the error counter will reach the maximum value and  
> close the association.
Correct.